Demo: Security Mechanisms Impact and Feasibility on Wireless Sensor Networks Applications

The deployment of security solutions in Wireless Sensor Networks (WSNs) is considered a challenge due to the highly constrained devices involved in these applications. However, due the need for security services such as confidentiality, integrity and authenticity in a large number of important scenarios, such mechanisms are made necessary. In this demonstration paper, we show that deployment of security algorithms on a WSN testbed is possible without causing significant impact on the performance of such applications. I. I  B Most WSN deployments do not consider security among their requirements. However, when targeting WSN for health applications or scenarios that monitor sensitive information, it is important to deploy confidentiality mechanisms. Furthermore, data integrity and authenticity are critical in order to prevent fake data that could lead to mistaken actions. Therefore, it becomes necessary to employ security mechanisms such as encryption algorithms and Message Authentication Codes (MACs) to provide confidentiality, integrity and authenticity in such scenarios. In order to use these algorithms, applications need to deal with the distribution of secret keys, which is a complex issue in these environments [8]. Law et al. [4] present a survey and benchmark of block ciphers that could be used in sensor networks, and choose AES [2] and Skipjack [5] for scenarios with, respectively, high and low security requirements. However, implementing regular algorithms and protocols that account for security is a difficult problem in such constrained environments. Hence, the drawback on using non-specific WSNs cipher algorithms usually is that one has to choose performance over security level or vice-versa. Security is often (and sadly) considered at the very last step in system design. Therefore, security tends to be looked at purely as an “extra cost” due to the execution/energy overhead it appears to add to the system. In this work, we show that security algorithms, such as encryption algorithms (namely C) and Message Authentication Code (MAC) algorithms (namely M) do not impact WSN applications significantly and can be used in WSNs. C [7] is a special-purpose block cipher tailored for constrained platforms, which takes 96-bit blocks organized as 3 × 4 byte matrices. It accepts 96-, 144or 192-bit keys and takes, respectively, 10, 14 or 18 rounds for its operation. Such as AES, this cipher also follows the Wide Trail Strategy and, thus, has a similar round structure built from four transformations: a Nonlinear Layerγ, in which all bytes in the block pass through a highly nonlinear S-Box; a Permutation Layer π, in which all the bytes in the second and third rows of the block are permuted to provide inter-columns diffusion; a Linear Diffusion Layer θ, in which the block is left-multiplied by an MDS matrix; and a Key addition Layer σ, in which the round key is XORed with the block. C accepts two versions for its key schedule. In the more conservative C-1, the key schedule structure is also based on the Wide Trail Strategy, while it takes the form of a linear feedback shift register in the C-2. The deployment of efficient Message Authentication Codes (MACs) is also an important issue in sensor networks. A reasonable strategy in such constrained scenarios is to adopt a cipher-based MAC, reducing the memory requirements for the MAC algorithm itself. M [6] algorithm was especially developed with constrained platforms in mind. It follows the ALRED construction, providing a trade-off for iterated block ciphers that process data blocks in chunks of fixed length. The M structure closely follows the randomize-thencombine paradigm, adopting a variant of Krawczyk’s hp(M) cryptographic CRC to generate secret offsets. These offsets are then combined with the message blocks by means of the so called Square Complete Transform, which corresponds to 4 unkeyed rounds of the underlying block cipher when this cipher belongs to the S family. II. T W S N S D This demo testbed is composed by Crossbow TelosB [1] motes running Contiki 2.2.1 OS [3]. This sensor node is a low power IEEE802.15.4 compliant wireless platform, which includes off-the-shelf temperature, humidity, light and infrared light sensors, as well as a 16-bit 8MHz Texas Instruments micro-controller with 10Kbytes of RAM and 48Kbytes of Flash memory. In order to show that security that algorithms do not impact WSN applications significantly and can be used in such scenarios, we create four WSNs, each of which has two nodes. The first WSN transmits and decodes received plain packets (i.e., no security mechanisms are used). The second WSN works with authenticated packets using M, while the third one encrypts data with C. The fourth one combines data encryption and authentication, using both C and M. Furthermore, as shown in Figure 1, there is also a spy node that monitors all data being transmitted by these networks. Fig. 1. Demonstration testbed setup. The data captured by the spy node, who is attached to a laptop through the USB port, is displayed in a console on the laptop. The spy node can understand both the data transmitted through the insecure network and the data from the authenticated network, but it will not understand data exchanged in the encrypted and encrypted/authenticated WSNs. Then we will be able to show that we can achieve confidentiality without performance loss. Data packets have 12 bytes in the plain insecure network, as well as on the encrypted data network. On the other hand, data packets have 16 bytes on both the authenticated and encrypted/authenticated networks due to the addition of the authentication tag. Given that all nodes are in range, receivers in all four networks will sense data from the other three networks. Since the networks operate with different data packet format, a packet from the encrypted/authenticated network may cause errors in the insecure network, and so on. In order to show if a packet is compliant to a given network or if it causes some kind of error, we will use the sensors’ LEDs. When the message format is as expected and the data value is acceptable, the green LED will turn on; conversely, the red LED will light if network message format is invalid or if a non-authenticated message is received (when an authenticated one was expected). If the message format is as expected and the authentication tag (if required) is valid, but an unexpected value is received, the blue LED will light. Table I summarizes which LEDs will turn on when data is received in a given network. Notice that with this combination of networks and types of data being transmitted/received, we were able to show the behavior of different levels of network security.